MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 139

Text File | 1996-03-23 | 115KB | 3,302 lines

C.S.M.P. Digest             Wed, 06 Mar 96       Volume 3 : Issue 139

Today's Topics:

        Bizarre trap patching problem
        FastRandom() source
        Hi ho, Hi ho, STR#ing we will go.
        How do I switch printers without the Chooser?
        On obtaining rowBytes... (Was Re: Video Memory Access)
        PEF (Preferred Executable Format) Info Needed
        Reconnecting Mounted Appleshare Volumes
        Stuck in a bottleneck
        USENET Macintosh Programming Awards (UMPA)
        [Q] NURBs and lighting
        pragma once vs #ifndef



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Nigel Stanger)
Subject: Bizarre trap patching problem
Date: 13 Feb 1996 01:16:02 GMT
Organization: Dept. of Information Science, University of Otago

This is weird -- I've written a patch to _Control (still working on this
MacTCP sending stuff), and it works fine... on 68k machines. If I install
it on my LC at home, the patch is activated fine and does what it's
supposed to. If I install it on my 6100 at work, the patch is again
activated fine and does what it's supposed to. _However_, after the patch
has finished executing, at some point I've been unable to determine tha
machine crashes with an illegal instruction. This occurs at a location in
low memory (somewhere around $70!), so I'm guessing that somewhere in
there is a jump to NIL.

The bit that's got me though is that this happens _after_ the patch has
finished executing and returned (I know this for a fact, I stepped through
it in MacsBug). How _long_ after is anyone's guess.

The only difference I can think of is that the patch in both cases is
being activated from Eudora, which is fat. When I run it at home, the
patch is called from 68k code. When I run it at work, it's called from PPC
code. Note that _Control gets called a lot by the OS without any hiccups
on both architectures. Is there something I should be doing that I'm not
aware of?

I do know that _Control is called at interrupt time, but I'm not aware of
anything I do that's dangerous in that respect; does that even matter in
the PPC environment anyway? I suppose it does, given that I'm patching a
68k trap with 68k code. But then, why does it crash on the PPC and not the
68k? Weird.

My code looks something roughly like this (CW8, BTW, and excuse any typos):

typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0;
ControlProcPtr gOldTrap;

#pragma parameter __D0 main(__A0)
OSErr main(ParmBlkPtr pb);

OSErr main(ParmBlkPtr pb:__A0):__D0
{
  TCPiopb *tcpPB = (TCPiopb)pb;

  if (pb->csCode == TCPSend)
  {
    // I can't remember the exact code here, but it goes something like this:
    // get stream ptr from tcpPB and stuff it into a TCPStatus PB
    if (PBControlSync(statusPB) == noErr)
    {
      if (statusPB.remotePort == 25) [SMTP]
      {
        // wdsEntry *theWDS = the WDS from tcpPB ;
        while (theWDS->length)
        {
          //if (theWDS->ptr == pattern)
             // beep (will eventually do things to WDS contents)
          else theWDS++;
        }
     }
  }
  gOldTrap(pb);
}

I might have to dig up the real code and post it. Anyway, can anyone see
anything obviously dangerous in the above?

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 13 Feb 1996 16:51:53 +1300
Organization: HyperMedia Unit, Comp Sci, Auckland University

In article <[e-mail]>,
[e-mail] (Nigel Stanger) wrote:

>This is weird -- I've written a patch to _Control (still working on this
>MacTCP sending stuff), and it works fine... on 68k machines. If I install
>it on my LC at home, the patch is activated fine and does what it's
>supposed to. If I install it on my 6100 at work, the patch is again
>activated fine and does what it's supposed to. _However_, after the patch
>has finished executing, at some point I've been unable to determine tha
>machine crashes with an illegal instruction. This occurs at a location in
>low memory (somewhere around $70!), so I'm guessing that somewhere in
>there is a jump to NIL.
>
>The bit that's got me though is that this happens _after_ the patch has
>finished executing and returned (I know this for a fact, I stepped through
>it in MacsBug). How _long_ after is anyone's guess.
>
>The only difference I can think of is that the patch in both cases is
>being activated from Eudora, which is fat. When I run it at home, the
>patch is called from 68k code. When I run it at work, it's called from PPC
>code. Note that _Control gets called a lot by the OS without any hiccups
>on both architectures. Is there something I should be doing that I'm not
>aware of?
>
>I do know that _Control is called at interrupt time, but I'm not aware of
>anything I do that's dangerous in that respect; does that even matter in
>the PPC environment anyway? I suppose it does, given that I'm patching a
>68k trap with 68k code. But then, why does it crash on the PPC and not the
>68k? Weird.
>
>My code looks something roughly like this (CW8, BTW, and excuse any typos):
>
>typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0;
>ControlProcPtr gOldTrap;
>
>#pragma parameter __D0 main(__A0)
>OSErr main(ParmBlkPtr pb);
>
>OSErr main(ParmBlkPtr pb:__A0):__D0
>{
>  TCPiopb *tcpPB = (TCPiopb)pb;
>
>  if (pb->csCode == TCPSend)
>  {
>    // I can't remember the exact code here, but it goes something like this:
>    // get stream ptr from tcpPB and stuff it into a TCPStatus PB
>    if (PBControlSync(statusPB) == noErr)
>    {
>      if (statusPB.remotePort == 25) [SMTP]
>      {
>        // wdsEntry *theWDS = the WDS from tcpPB ;
>        while (theWDS->length)
>        {
>          //if (theWDS->ptr == pattern)
>             // beep (will eventually do things to WDS contents)
>          else theWDS++;
>        }
>     }
>  }
>  gOldTrap(pb);
>}
>
>I might have to dig up the real code and post it. Anyway, can anyone see
>anything obviously dangerous in the above?

What about calling thru to the original trap with the proper mixed mode
call? I patched _PBMountVol and the guts of the patch looked like this:



#if !GENERATINGCFM
OSErr main (ParmBlkPtr PBPtr:__A0):__D0
#else
ProcInfoType __procinfo = uppPBMountVolProcInfo;
OSErr main (unsigned short TrapWord,ParmBlkPtr PBPtr)
#endif

{
#if !GENERATINGCFM
// Set up "A4 World"
long SavedA4 = SetCurrentA4();
#endif


// Get globals

   Err = Gestalt(gestaltGlobals,(long*)&Globals);
   if (Err != noErr)
   {
      DebugStr("\p_Gestalt FAILED");
      goto Done;
   }


// Call old trap

#if GENERATINGCFM

// DebugStr("\pPPC;G");

   Err =
CallOSTrapUniversalProc((*Globals).OldPBMountVol,uppPBMountVolProcInfo,TrapWord,PBPtr);
   if (Err != noErr)
   {
      DebugStr("\p_CallOSTrapUniversalProc((*Globals).OldPBMountVol) FAILED");
      goto Done;
   }

#else

// DebugStr("\p68K;G");

   Err = ((PBMountVolProc)((*Globals).OldPBMountVol))(PBPtr);
   if (Err != noErr)
   {
      DebugStr("\p(*Globals).OldPBMountVol() FAILED;G");
      goto Done;
   }

#endif


// Body of function (this is a "head" patch)


Done:
#if !GENERATINGCFM
   SetA4(SavedA4);
#endif

   return Err;
}


The different function prototypes was something to do with Metrowerks
pushing the TrapWord on the stack for OS traps (this may not be required
anymore??).

A ptr to my globals was stored as a Gestalt value (check out the
GestaltValue libraries around the place).

On thinking about it, I may not have needed the "#if GENERATINGCFM" in the
body of the function as this functionality is probably provided in
CallOSTrapUniversalProc.


Hope this helps...

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x5602
Fax:      [phone]                         Async, Therefore I Am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (James W. Walker)
Date: Mon, 12 Feb 1996 21:32:51 -0800
Organization: Nisus Software, Inc.

In article <[e-mail]>,
[e-mail] (Nigel Stanger) wrote:

>My code looks something roughly like this (CW8, BTW, and excuse any typos):

>typedef OSErr (*ControlProcPtr)(ParmBlkPtr pb:__A0):__D0;
>ControlProcPtr gOldTrap;

>#pragma parameter __D0 main(__A0)
>OSErr main(ParmBlkPtr pb);

>OSErr main(ParmBlkPtr pb:__A0):__D0
>{
... stuff deleted
>  gOldTrap(pb);
>}

A couple of ideas:

1. Your function fails to return a value.  Was that just a typo in your
post, or a real error?

2. _Control needs to look at register D1 to tell whether it is a
synchronous or asynchronous call, right?  But by the time you call
gOldTrap, your code may have munged D1. For that matter, are you sure you
don't need to know if you're synchronous?
--
  --  Jim Walker

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 13 Feb 1996 13:31:46 GMT
Organization: Ecole Normale Superieure, Paris, France

In article <[e-mail]>,
Nigel Stanger <[e-mail]> wrote:

>    // I can't remember the exact code here, but it goes something like this:
>    // get stream ptr from tcpPB and stuff it into a TCPStatus PB
>    if (PBControlSync(statusPB) == noErr)

You're making a synchronous call at interrupt time here. Are you sure
this is OK? I'm no expert in these matters, but I think you might have
to make an asynchronous call (only if your patch was called
asynchronously, of course) and do the rest of your stuff from the
completion routine.

Just my $0.01,


--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Tue, 13 Feb 1996 12:32:31 -0800
Organization: Apple Computer

In article <[e-mail]>,
[e-mail] (Chris Burns) wrote:

[original text/reply snipped]

> The different function prototypes was something to do with Metrowerks
> pushing the TrapWord on the stack for OS traps (this may not be required
> anymore??).

Quick fyi here.  The requirement for the trap word to be the first
parameter in patched OS traps IS NOT a necessity brought on my
CodeWarrior.  It's a requirement for patching OS traps period.  Look at IM
PowerPC System Software for the details (sorry I don't have the page #
handy).  If you are patching any OS trap, you will get and have to pass
through the trap word as the first parameter.

Before even attempting to suggest things for the crash itself, can you
post/send the source for your patching and UPP procInfo declarations?

Cheers,
dEVoN

+++++++++++++++++++++++++++

>From [e-mail] (Nigel Stanger)
Date: 14 Feb 1996 01:17:48 GMT
Organization: Dept. of Information Science, University of Otago

In article <[e-mail]>,
[e-mail] (Chris Burns) wrote:

> What about calling thru to the original trap with the proper mixed mode
> call? I patched _PBMountVol and the guts of the patch looked like this:
[...snip...]

This is something I thought of the other day, but I didn't know enough
about the mechanics of mixed mode stuff to figure out how to do it (I've
read the article in develop 16, but that's about it). Your example might
be enough for me to figure out what to do. I'll try it and see. Thanks!

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Nigel Stanger)
Date: 15 Feb 1996 22:23:16 GMT
Organization: Dept. of Information Science, University of Otago

In article <[e-mail]>,
[e-mail] (James W. Walker) wrote:

> A couple of ideas:
>
> 1. Your function fails to return a value.  Was that just a typo in your
> post, or a real error?

It's just a typo. The real code actually looks like this:

OSErr theErr;
...
theErr = gOldTrap(pb);
...
return theErr;

> 2. _Control needs to look at register D1 to tell whether it is a
> synchronous or asynchronous call, right?  But by the time you call
> gOldTrap, your code may have munged D1. For that matter, are you sure you
> don't need to know if you're synchronous?

Now that's a damn good point, and something that doesn't seem to be very
well documented (I certainly haven't seen it anywhere obvious). Any
suggestions on how to stop it getting stomped on?

As to whether it's sync or async, I don't think it really matters from the
point of view of my code. What I'm doing is inspecting the contents of the
outgoing SMTP stream, and changing certain elements of it (for useful
purposes I might add :) Whether it's async or sync is pretty much
irrelevant, I think.

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (John L. Scott)
Date: Fri, 16 Feb 1996 15:40:25 GMT
Organization: The Institute for Genomic Research

In article <[e-mail]>,
[e-mail] (Nigel Stanger) wrote:

> In article <[e-mail]>,
> [e-mail] (James W. Walker) wrote:
>
> > 2. _Control needs to look at register D1 to tell whether it is a
> > synchronous or asynchronous call, right?  But by the time you call
> > gOldTrap, your code may have munged D1. For that matter, are you sure you
> > don't need to know if you're synchronous?
>
> Now that's a damn good point, and something that doesn't seem to be very
> well documented (I certainly haven't seen it anywhere obvious). Any
> suggestions on how to stop it getting stomped on?

In CodeWarrior at least, you can do this:

#pragma parameter __D0 MyPBControl(__D1, __A0)

pascal OSErr MyPBControl(unsigned short trapWord, TCPParmBlkPtr paramBlock)

> As to whether it's sync or async, I don't think it really matters from the
> point of view of my code. What I'm doing is inspecting the contents of the
> outgoing SMTP stream, and changing certain elements of it (for useful
> purposes I might add :) Whether it's async or sync is pretty much
> irrelevant, I think.

Ah but it is relevant.  If you make a synchronous call to a device driver
at interupt time, you may deadlock the driver.  If you want to intercept
asynchronous call you'll have to make your calls asynchronous as well.  I
wouldn't worry about using a completion routine though.  Make your call
and busy-wait until it's complete, then move on.  This scheme should work
whether the intercepted call is asyncronous or not.

--John Scott

+++++++++++++++++++++++++++

>From [e-mail] (Nigel Stanger)
Date: 19 Feb 1996 01:18:08 GMT
Organization: Dept. of Information Science, University of Otago

In article <jlscott-1602961040250001@192.207.234.72>, [e-mail]
(John L. Scott) wrote:

> In CodeWarrior at least, you can do this:
>
> #pragma parameter __D0 MyPBControl(__D1, __A0)
>
> pascal OSErr MyPBControl(unsigned short trapWord, TCPParmBlkPtr paramBlock)

Yep, I thought of that myself, tried it a couple of nights ago, and now it
works! No more crashes! Whee! :)

> Ah but it is relevant.  If you make a synchronous call to a device driver
> at interupt time, you may deadlock the driver.  If you want to intercept
> asynchronous call you'll have to make your calls asynchronous as well.  I
> wouldn't worry about using a completion routine though.  Make your call
> and busy-wait until it's complete, then move on.  This scheme should work
> whether the intercepted call is asyncronous or not.

Oh, OK, I should be able to code that in about 10 minutes. Thanks!

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

---------------------------

>From Andrew Welch <[e-mail]>
Subject: FastRandom() source
Date: Tue, 13 Feb 1996 18:54:00 -0500
Organization: Ambrosia Software, Inc.

While converting an application to be PowerPC native, I noticed that an A-Trap
it made heavy use of (_Random) was not yet native.  So I did a quick and dirty
translation of the _Random 68K assembler code into C.

It's pretty self-explanitory -- call FastRandom(0) to initialize the random
number seed, or pass any positive value in the range parameter to generate a
psuedo-random number between 0..range - 1

Enjoy... and remember, you get what you pay for. :)

//
- ----------------------------------------------------------------------------
- -
// -- Return a random value between 0 and range - 1

short FastRandom(short range)
{
short        result;
static        unsigned    long                randomSeed;
register    unsigned    long                calc;
register    unsigned    long                regD0;
register    unsigned    long                regD1;
register    unsigned    long                regD2;

if (range == 0)
    randomSeed = LMGetTicks() + LMGetTime();
else
    {
    calc = randomSeed;
    regD0 = 0x41A7;
    regD2 = regD0;

    regD0 *= calc & 0x0000FFFF;
    regD1 = regD0;

    regD1 = regD1 >> 16;

    regD2 *= calc >> 16;
    regD2 += regD1;
    regD1 = regD2;
    regD1 += regD1;

    regD1 = regD1 >> 16;

    regD0 &= 0x0000FFFF;
    regD0 -= 0x7FFFFFFF;

    regD2 &= 0x00007FFF;
    regD2 = (regD2 << 16) + (regD2 >> 16);

    regD2 += regD1;
    regD0 += regD2;

    if (regD0 < 0)
        regD0 += 0x7FFFFFFF;

    randomSeed = regD0;

    if ((regD0 & 0x0000FFFF) == 0x8000)
        regD0 &= 0xFFFF0000;

// -- Now that we have our pseudo random number, pin it to the range we want

    regD1 = range;
    regD1 *= (regD0 & 0x0000FFFF);
    regD1 = (regD1 >> 16);

    result = regD1;
    }


return result;
}    // -- FastRandom

--
+--------------------------------------------------------------+
|    Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.    |
+-------------------------------+------------------------------+
|    AOL-> Keyword: Ambrosia    |  eWorld-> Shortcut: Ambrosia |
|    CIS-> GO word: Ambrosia    |  http://www.AmbrosiaSW.com/  |
+-------------------------------+------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Michel Saucier)
Date: Sat, 17 Feb 1996 16:20:14 -0400
Organization: Bell Global Solutions

About FastRandom()...

 Here is another algorithm to generate pseudorandom values.
 It's quite fast, faster than the classic congruential method, and
generates 32 random bits
 at each call, instead of 16. It uses only XOR and AND, (no MULT, DIV or MOD).

 It needs a 1024 bits seed (32 longints) and has a period of 4294967295.
 Changing the seed values gives a completely different sequence, instead of
 merely changing the starting point.

 The function is only two lines of C. The only hard part is to initialize
the startup array
 with 32 uncorrelated full-32 bits values, a non-trivial task, as the
NetScape's folks can attest!
      This is left as an exercice.

 The code:

static unsigned long AInd=0;
static unsigned long AMem[32];
unsigned long alea(void) /* LFSR-based random generator, with a 32
longwords memory */
{ unsigned long i=AInd++%32; /* 32 LFSR are maintained in parallel, bitwise */
  return AMem[i]^=AMem[(i+1)%32]^AMem[(i+2)%32]
^AMem[(i+4)%32]^AMem[(i+6)%32]^AMem[(i+31)%32];
}

  And the related functions:

long ralea(long range) /* return a pseudorandom value in 1..range */
{return 1+alea()%range;}

static long LHseed=1; /* please kindly CHANGE ME */
unsigned long lehmer(void)/* Lehmer algorithm, Schrage's method to avoid
overflow */
{long hi=LHseed/127773L,lo=LHseed%127773L; /* a very smart compiler would
DIV once */
 long t=lo*16807L - hi*2836L;
 return LHseed=(t>0)?t:t+2147483647L;
}

int checkAMem(void) /* 0 means AMem[] is unacceptable, 1 means OK */
{ int i; unsigned long t;
   for(i=0,t=0;i<32;i++) t|=AMem[i]; /* Test AMem[] bitwise */
   return 0==~t; /* all columns contain at least one non-zero bit? */
}

void initAMem(void) /* stretches out a 31 bits seed to create 1024 bits
seed. Avoid.  */
{ int i; LHseed=(long)clock();
  for(i=0;i<32;i++) AMem[i]=lehmer()^lehmer()<<16; /* do not use this one
in real life */
  assert(0!=checkAMem()); /* should be extremely rare */
}


  Thou shalt not tamper with the alea() algorithm. It applies a CRC-type
polynom bitwise,
maintaining 32 LFSR-like sequences. Any "amelioration", like ADDing the 5
values instead of XORing them, or smartly ROTating the XOR result, is
*VERY* likely to drastically _reduce_ the period
of the generator.
Consider this as a fair warning. And don't ever use alea() for cryptography.

  NO ONE ever abolish'd randomness by a crapshoot. (Mallarme)

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Michel Saucier)
Date: Mon, 19 Feb 1996 00:14:17 -0400
Organization: Bell Global Solutions

About alea()...

static unsigned long AInd=0;
static unsigned long AMem[32];
unsigned long alea(void)     /* LFSR-based random generator, with a 32
longwords memory */
{ unsigned long i=AInd++%32; /* 32 LFSR are maintained in parallel, bitwise */
  return AMem[i]^=AMem[(i+1)%32]^AMem[(i+2)%32]
^AMem[(i+4)%32]^AMem[(i+6)%32]^AMem[(i+31)%32];
}

The function is only two lines of C. The only hard part is to initialize
the startup array with 32 uncorrelated full-32 bits values, a non-trivial
task, as the NetScape's folks can attest!

>> Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.
>> Interesting.  How would you suggest initializing those values?

In fact, if all you want is an honest and fast pseudo-random numbers generator,
any set of 32 bits values is sufficient, provided no bit position contains
a 0 on all 32 longwords, and there is no trivial pattern in the values.
  "0F0FF0F00F0F..." would definitvely be a bad startup seed.
The checkAMem() will cause an assert() error for these degenerate cases.

 So you can use the MAC/OS (16 bits) or the C (31 bits) random generator,
and use it
to seed the AMem[] startup array. The period of the alea() generator will
still be maximum.
The only downside is that a 16 bits "streched seed" can only construct
32768 different
startup arrays (each one producing 4294967295 random numbers without
repetition), instead
of having potentially 2^1024 different random generators, each one
generating a unique
sequence of 2^32 longwords of 32 random bits. Do you dig the difference ?

 It's only when you are using this random generator in cryptography that
you MUST build
a completely unguessable 1024 bits startup seed.
 There are many ways to achieve this:

    - Have the user flip a coin 1024 time (unobserved by anyone) and
record the results.

    - Attach a Geiger counter to the computer.

    - Sample the ambiant noise by a microphone attached to the mac.

    - Have the user type a LONG passphrase. Discard the ASCII codes, use
instead the
        timing between the keystrokes.

    - Build a composite of many values taken in the hardware or the
operating system:
         clock, current address, timebase registers, performance
registers, total number
         of cache hits, number of bytes processed by the file system,
current mouse position,
         XOR of the display screen bitmap, current scanline, etc... etc..

See Bruce Shneier "Applied Cryptography", chapter 15, for more on this topic.
See also Colin Plumb "Truly Random Numbers", Dr Dobb's Journal, November
1994, for a background
task who collects mouseclics and keypresses, and integrates them in a pool
"stirred" by the
well-known hash MD5.

______________________________________________

 I haven't yet timed my routine alea() against lehmer() on a PowerMac. On
my 68040's 660AV,
I have timed 350000 calls to alea() by second, against 142000/s for
lehmer(), the typical
congruential generator. If I optimize lehmer() in assembly, they are about
the same speed.

lehmer::
    MOVE.L  seed,D1
    DIVS.L  #127773,D0:D1 ; Quotient and remainder
    MULS.L  #16807,D0
    MULS.L  #2836,D1
    SUB.L   D1,D0
    BGT.S   @1
    ADD.L   #1247483647,D0
@1: MOVE.L  D0,seed
    RTS

alea() is about 40 instructions long, but slightly faster because it
contains no MULt, DIV
nor BRanches, only XOR, ANDs, and addressing. There are 6 memory reads and
2 writes.
When alea() is used to initialize a long list of random values, the AMem[]
array fits nicely
in the processor cache.

  I am still searching a way to increase the period of the generator to 2^1024,
but any tampering, like INCrementing the XORed values, will void the
mathematical property
which assure of a 2^32-1 period. On can, of course, combine the output of
the generator with
another random generator of a different period.

  If the (parallel) LFSR is used alone, an astute cryptographer needs only
32 words or less
known plaintext to reconstruct the initialisation vector and decrypt the
mrest of the message(s).

 "God do not play with dice" A. Einstein

Michel Saucier, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Milo Shiff)
Date: 20 Feb 1996 07:17:43 GMT
Organization: Los Angeles Macintosh Group BBS

In message ID <[e-mail]> on 2/13/96, [e-mail]
wrote:

a> While converting an application to be PowerPC native, I noticed
a> that an A-Trap  it made heavy use of (_Random) was not yet native.
a> So I did a quick and dirty  translation of the _Random 68K
a> assembler code into C.

   If speed is of utmost concern, build a table of random numbers at or
before compile time. Make sure the table is large enough to meet your
intended purposes.

   On the other hand, if a reliable pseudo-number generator is desired, use
well proven methods, duplicated ubiquitously in various books.

- Sent via BulkRate 2.1

---------------------------

>From Daniel Bogan <[e-mail]>
Subject: Hi ho, Hi ho, STR#ing we will go.
Date: Fri, 02 Feb 1996 10:45:13 +1000
Organization: Big Hand Asia Pacific

While i'm in a -in-need-of-help binge...

Can someone supply me with code (THINK C) on how to write Str255's
back out to a STR# resource. Say, I have 5 Str255's and I want to write
them out to the one STR# resource in the order I supply.

I'll probably think of something else to ask pretty soon. I can feel it.

Ta.

+++++++++++++++++++++++++++

>From [e-mail] (Shawn V. Hernan)
Date: 2 Feb 1996 17:31:14 GMT
Organization: The University of Pittsburgh

In article <[e-mail]>
Daniel Bogan <[e-mail]> writes:

> Can someone supply me with code (THINK C) on how to write Str255's
> back out to a STR# resource.


The press is in love with the World Wide Web, but usenet is still where
all the cool stuff happens. Not two days ago, I had the same question.
There is some good sample code at

<http://www.AmbrosiaSW.com/cgi-bin/getsnippet.pl?file=/alt.sources.mac/s
nippets-v01/packstr255>

The basic idea is to implement the C structure yourself (an int
followed by asciiz strings) and use AddResource (or similar) to
actually do the writing.

Two key points I discovered are :

1) If you're using an already exisitng resource, be sure to call
DetachResource.

2) If you're building your own resource in memory be create a real
handle using NewHandle or similar, and be sure to lock it prior to
making changes.

Thanks to Dave Nebinger, Jim Derry, Francis H. Shiffer, Paulo Casanova,
Maf Vosburgh and others for the info .

Shawn

Shawn V. Hernan                 |
Systems and Networks            |
The University of Pittsburgh    |  Dump the RICO Laws
[e-mail]                   |
412-624-6425                    |

+++++++++++++++++++++++++++

>From [e-mail] (Yennie)
Date: 5 Feb 1996 16:58:23 -0500
Organization: America Online, Inc. (1-800-827-6364)

Something like this (warning this is Compileit! style junk and just a
stab-- it might be useless)

put newHandle(length(strings)+numStrings) into STRhand
put STRhand@ into STRptr
HLock STRhand
put STR1 into STRptr@.str255Type
put STRptr + (length(STR1)+1) into STRptr
put STR2 into STRptr@.str255Type
put STRptr + (length(STR2)+1) into STRptr
put STR3 into STRptr@.str255Type
put STRptr + (length(STR3)+1) into STRptr
put STR4 into STRptr@.str255Type
put STRptr + (length(STR4)+1) into STRptr
put STR5 into STRptr@.str255Type
HUnlock STRhand
AddResource STRhand,bla bla,bla bla,bla bla --(I can't remember the order
of params for "AddResource")
WriteResource STRhand -- if you need it now

Hope this helps...


+++++++++++++++++++++++++++

>From [e-mail] (Dave M Brosius)
Date: 17 Feb 1996 08:00:37 GMT
Organization: Chester County Internet Services, Inc.

In article <[e-mail]>, [e-mail] wrote:

> While i'm in a -in-need-of-help binge...
>
> Can someone supply me with code (THINK C) on how to write Str255's
> back out to a STR# resource. Say, I have 5 Str255's and I want to write
> them out to the one STR# resource in the order I supply.
>
> I'll probably think of something else to ask pretty soon. I can feel it.
>
> Ta.


Handle   CreateStrPound( StringPtr *pStrings, long lStrCount )
{
   Handle hStrPound;
   char   *pDst;
   long   lCurString;
   long   lSize;

   for (lCurString = 0, lSize = 0;
        lCurString < lStrCount;
        lSize += pStrings[lCurString][0] + 1, lCurString++
       );

   hStrPound = NewHandle( lSize );
   ThrowIfNull( hStrPound ); // C++ was invented for those who don't
                             // want to document error handling

   HLock( hStrPound );
   for (lCurString = 0, pDst = *hStrPound;
        lCurString < lStrCount;
        pDst += pString[lCurString][0]+1, lCurString++
       )
      memcpy( pDst,
              pString[lCurString],
              ((unsigned char) pString[lCurString][0])+1 );

   HUnlock( hStrPound );
   return hStrPound;
}

--
Please reply via email as well
dave [e-mail]

---------------------------

>From [e-mail] (Jason Richmond)
Subject: How do I switch printers without the Chooser?
Date: Sat, 03 Feb 96 20:40:46 GMT
Organization: Montana Communications Network

I am writing an application for the Mac and I need to send output to two
different network printers. I need to do this from within the program, hidden
from the user. Is there any way to do this?

+++++++++++++++++++++++++++

>From [e-mail] (The Grinch)
Date: 8 Feb 1996 21:56:22 GMT
Organization: Vortex Software

Don't quote me, but I think the answer lies in extended PRAM, which you're
really not supposed to mess with. (Like that ever stops anybody.) As far
as I know, the only way to change XPRAM is through assembly. If you figure
it out, I'd love to see the source!

Good luck!
-The Grinch

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 10 Feb 1996 12:03:23 -0800
Organization: Cellular

In article <4f06q3$[e-mail]>,
[e-mail] (Jason Richmond) wrote:

 > I am writing an application for the Mac and I need to send output to two
 > different network printers. I need to do this from within the program,
hidden
 > from the user. Is there any way to do this?

No. Network printer drivers expect to be chosen with Chooser. In the case
of LaserWriter, for example, when you choose a new printer, the driver
verifies what kind of LaserWriter it is and chooses a PPD file for it. I
expect other drivers perform similar stunts.

If for some reason you are writing an application which is guranteed to
run in a closed environment (ex.: LaserWriter guaranteed), you might
choose to [a] select the generic LaserWriter PPD in Chooser, [b] have your
program modify the 'PAPA' resource in the driver itself, [c] remove
Chooser from the system so the user can't confuse things. Of course, this
has a number of limitations, not least of which is it will eventually
break, it will limit you to LaserWriters, it will disable any fun features
of individual printers, etc. etc.

- -----------------------------

  Pete Gontier -- Apple Macintosh Developer Technical Support
  <URL:mailto:[e-mail]> -- <URL:http://www.dnai.com/~gurgle>

+++++++++++++++++++++++++++

>From [e-mail] (Carl Gustafson)
Date: Mon, 12 Feb 1996 12:42:17 -0500
Organization: Imaging and Computer Vision Center, Drexel University

In article <4f06q3$[e-mail]>, [e-mail] (Jason Richmond) wrote:

> I am writing an application for the Mac and I need to send output to two
> different network printers. I need to do this from within the program, hidden
> from the user. Is there any way to do this?

There are a few resources in the System file that tell what printer driver
and printer to use. Changing them will change the selected printer, but I
don't recall what the resources are, nor do I particularly recommend doing
it. OTOH, it is a free country, so try if you like.

--
Carl Gustafson
Imaging and Computer Vision Center
Drexel University, Philadelphia, Penna
- ----------------------------------------------------------
I don't speak for Drexel, and Drexel doesn't listen to me...

+++++++++++++++++++++++++++

>From [e-mail] (Dan Schwarz)
Date: Wed, 21 Feb 1996 03:37:32 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <4f06q3$[e-mail]>, [e-mail] (Jason Richmond) wrote:

> I am writing an application for the Mac and I need to send output to two
> different network printers. I need to do this from within the program, hidden
> from the user. Is there any way to do this?

Yes, but it's an awful lot of work. My shareware program, "PrinterSwitch"
does this; it took a couple weeks of (part-time) coding to get the switching
code working properly. You can check it out at:

http://www.cs.brandeis.edu/~dan/home.html

Basically, what you have to do is this:

Write the appropriate 'alis' and 'STR ' resources into the System
file, these point to the printer driver you want to use.

Write the appropriate 'PAPA' and/or 'PSEL' resourcs into the printer driver's
resource fork.

Switch to the appropriate parsed PPD file (if you're using LaserWriter 7 or 8
drivers)

... but where to find the "appropriate" resources and PPD resources to use?
aha! that's the tough part. You have to make the user switch to the printer(s)
that are to be used, each in turn, then your code will have to read in these
resources and store them away safely somewhere. That's what I do.
If you have total control over the environment in which your application is to be used, i.e. this is an in-house application to run on one system, you can
prep this stuff ahead of time and store it in your application.

For more info, I highly recommend reading Apple's Printing Q&As, and
the issue of Develop magazine that talked about fun with PRGeneral and other
printing tips. You can find both on the web, at http://www.dev.info.apple.com/

good luck!

_Dan





---------------------------

>From Lawson English <[e-mail]>
Subject: On obtaining rowBytes... (Was Re: Video Memory Access)
Date: 11 Feb 1996 09:26:02 -0700
Organization: Primenet [phone]

Chris De Salvo <[e-mail]> wrote:
[snipt]
:    rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF;

All the working code samples that I have uses 0x3fff, not 0x7fff.


Anyone know if it makes any difference in the real world?


--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 11 Feb 1996 10:32:12 -0800
Organization: Internet for the Olympic Peninsula

In article <4fl5aq$[e-mail]>, Lawson English
<[e-mail]> wrote:

>Chris De Salvo <[e-mail]> wrote:
>[snipt]
>:    rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF;
>
>All the working code samples that I have uses 0x3fff, not 0x7fff.
>
>
>Anyone know if it makes any difference in the real world?

Hi, Lawson,

   I'm not sure it makes any current real-world difference.  However, the
value rowBytes is specified as being less than 0x4000 (IM: Imaging with
QuickDraw, page 4-47), and the top two bits are specified as being used as
flags.  No use of bit 14 is given on that page (leaving a few other IM
pages where it might be--a check of Advanced Color Imaging would be a good
idea, but I can't lay hands on it in paper form right now and don't feel
like checking a CD version).

   --John

--
  The primary cause of problems is solutions.
John W. Baxter    Port Ludlow, WA     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David M. Palmer)
Date: 11 Feb 1996 13:51:14 -0500
Organization: Clark Internet Services, Inc., Ellicott City, MD USA

Lawson English <[e-mail]> writes:

>Chris De Salvo <[e-mail]> wrote:
>[snipt]
>:    rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF;

>All the working code samples that I have uses 0x3fff, not 0x7fff.


>Anyone know if it makes any difference in the real world?

I believe it does.  I seem to remember seeing Rowbytes 0xC??? on something
I was doing recently, possibly in a GWorld.

I didn't see the basenote, so I don't know if this has been mentioned, but
other things I have learned about GWorlds, which you may as well do even
if you are using screen memory: Make sure that you use
GetPixBaseAddress(pixmap), or whatever the call is, to get the address
of the actual pixels.  (Sometimes pixmap.baseaddress is a pointer, and
sometimes a handle, depending.)  And call SetPixelsState(pixmap, LockPixels)
if you do something that might move memory after you get the address.

--
            David Palmer
            [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jean-Francois Brouillet)
Date: Mon, 12 Feb 1996 21:12:57 +0100
Organization: Francenet -- Paris, France

In article <4fldr2$[e-mail]>, [e-mail] (David M. Palmer) wrote:

>Lawson English <[e-mail]> writes:

[question about mask to apply to rowBytes (0x7fff or 0x3fff)]

Using DejaNews, I found the following article which may explain what these
bits are used for...

Here's the entire article (which deals with how to retreive the palette
stored within a PICT file). The portion relevant to this thread is in the
ColorBitsProc routine...

hope this helps...


[BTW: I needed some thing like this, ant this code does work!]

sender: [e-mail]
references: <[e-mail]> <466grp$[e-mail]>
content-type: text/plain; charset=ISO-8859-1
organization: NETCOM On-line Communication Services (408 261-4700 guest)
mime-version: 1.0
newsgroups: comp.sys.mac.programmer.help

In article <466grp$[e-mail]> John S. Heaney, [e-mail]
writes:
>In article <[e-mail]>, Darren Giles  <[e-mail]> wrote:
>>I need to get a color table out of an 8-bit PICT.  I know one way to do
>>it is to use GetPictInfo, which generates a color table based on the
>>pixels it sees in the picture...  but I need to get the original color
>>table.
>
>I've wanted to do that, too. I'm surprised that there doesn't seem to be
>a way to do this built into the toolbox, considering all the other
>powerful tools.

No kidding!  Well, I've patched together a start based on the
CollectPictColors
snippet (using the QDraw bottleneck idea, as Nicholas (and DTS)
suggested).
Here's what I've got so far, in case others are trying to do the same:

- Darren


CTabHandle gColorTable; /* to collect colors from bottlenecks. */

///////////////////////////////////////////////////////////////////////
/////////////////
//   Looks though the PICT, returns a copy of the CLUT of the first
bitmap it encounters.
///////////////////////////////////////////////////////////////////////
/////////////////
CTabHandle CollectColors (PicHandle fromPicture) {
        CQDProcs bottlenecks;


        if (!fromPicture) {
                return nil;
        }

        /* Set the bottlenecks.  These bottlenecks will figure out what colors
are in
                a picture, but won't draw anything.
        Note: the bottlenecks are installed in thePort, which must be a color
port.
        */
        SetStdCProcs(&bottlenecks);
        bottlenecks.textProc = nil;
        bottlenecks.lineProc = nil;
        bottlenecks.rectProc = nil;
        bottlenecks.rRectProc = nil;
        bottlenecks.ovalProc = nil;
        bottlenecks.arcProc = nil;
        bottlenecks.polyProc = nil;
        bottlenecks.rgnProc = nil;
        bottlenecks.bitsProc = NewQDBitsProc (ColorBitsProc);

        gColorTable= nil;

        /* Now play back the picture to get the colors.  The dstRect doesn't
                matter since our bottlenecks will never actually draw. We
use global
                variables (gColorError and gColorTable) to communicate with the
                bottlenecks. */
        (*(qd.thePort)).grafProcs = (QDProcs *) &bottlenecks;
        DrawPicture(fromPicture, &((**fromPicture).picFrame));
        (*(qd.thePort)).grafProcs = 0L;

        return gColorTable;
}

///////////////////////////////////////////////////////////////////////
/////////////////
pascal void ColorBitsProc(BitMap *bitPtr, Rect *srcRect, Rect *dstRect,
short mode, RgnHandle maskRgn) {
#pragma unused (srcRect, dstRect, mode, maskRgn)
        PixMapPtr               aPixMap;
        short                   tempRB;
        Handle                  CTHandle;


  /* Get the PixMap that we are about to draw.  SrcBits might be a BitMap,
   or one of two different kinds of PixMap pointers.  */

    tempRB = (*bitPtr).rowBytes;    /* local copy of rowBytes */
    if (tempRB & 0x8000) {          /* high bit set? */
        if (tempRB & 0x4000) {      /* next to high bit set? */
            /* ptr to PixMap handle */
            aPixMap = (** ( (PixMapHandle *)bitPtr ));
        }
        else {
            /* pointer to a PixMap */
            aPixMap = (PixMapPtr) bitPtr;
        }

        if ((*aPixMap).pixelType==16) {
                return;
            /* direct pixmap?  eek! */
        }

        if (!gColorTable) {
            CTHandle= (Handle) (*aPixMap).pmTable;
            gColorTable= (CTabHandle) NewHandle (GetHandleSize (CTHandle));
            BlockMove (*CTHandle, *gColorTable, GetHandleSize (CTHandle));
        }
    }
}

--
Jean-Francois Brouillet              [e-mail]
Macintosh Software Developer     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Tue, 13 Feb 96 19:08:42 +0300
Organization: (none)

In article <[e-mail]>,
[e-mail] (John W. Baxter) wrote:

>In article <4fl5aq$[e-mail]>, Lawson English
><[e-mail]> wrote:
>
>>Chris De Salvo <[e-mail]> wrote:
>>[snipt]
>>:    rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF;
>>
>>All the working code samples that I have uses 0x3fff, not 0x7fff.
>>
>>
>>Anyone know if it makes any difference in the real world?
>
>   I'm not sure it makes any current real-world difference.  However,
the
>value rowBytes is specified as being less than 0x4000 (IM: Imaging
with
>QuickDraw, page 4-47), and the top two bits are specified as being
used as
>flags.  No use of bit 14 is given on that page (leaving a few other IM
>pages where it might be--a check of Advanced Color Imaging would be a
good
>idea, but I can't lay hands on it in paper form right now and don't
feel
>like checking a CD version).

They were just too lazy to point out in IM that the *only* bit is
used to distinguish between color and b&w BitMaps, and the only case
when the *second* bit is used is when you pass PixMap as a parameter
to CopyBits procedure. The latter restriction could be bypassed via
several ways.

- --------------------------------------------------------------
Michael Kluev                            [e-mail]
Macintosh Programmer                           Physics Grad, MSU
MACsimum Ltd.                                     Moscow, Russia
- --------------------------------------------------------------

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Tue, 13 Feb 96 07:14:23 GMT
Organization: Streetly Software


In article <[e-mail]>, Jean-Francois Brouillet writes:

>
> In article <4fldr2$[e-mail]>, [e-mail] (David M. Palmer) wrote:
>
> >Lawson English <[e-mail]> writes:
>
> [question about mask to apply to rowBytes (0x7fff or 0x3fff)]
>
[snip]
>         SetStdCProcs(&bottlenecks);
[snip]
>         bottlenecks.bitsProc = NewQDBitsProc (ColorBitsProc);
>
> ///////////////////////////////////////////////////////////////////////
> /////////////////
> pascal void ColorBitsProc(BitMap *bitPtr, Rect *srcRect, Rect *dstRect,
> short mode, RgnHandle maskRgn) {
> #pragma unused (srcRect, dstRect, mode, maskRgn)
>         PixMapPtr               aPixMap;
>         short                   tempRB;
>         Handle                  CTHandle;
>
>
>   /* Get the PixMap that we are about to draw.  SrcBits might be a BitMap,
>    or one of two different kinds of PixMap pointers.  */
>
>     tempRB = (*bitPtr).rowBytes;    /* local copy of rowBytes */
>     if (tempRB & 0x8000) {          /* high bit set? */
>         if (tempRB & 0x4000) {      /* next to high bit set? */
>             /* ptr to PixMap handle */
>             aPixMap = (** ( (PixMapHandle *)bitPtr ));
>         }
>         else {
>             /* pointer to a PixMap */
>             aPixMap = (PixMapPtr) bitPtr;
>         }
>
>         if ((*aPixMap).pixelType==16) {
>                 return;
>             /* direct pixmap?  eek! */
>         }
>
>         if (!gColorTable) {
>             CTHandle= (Handle) (*aPixMap).pmTable;
>             gColorTable= (CTabHandle) NewHandle (GetHandleSize (CTHandle));
>             BlockMove (*CTHandle, *gColorTable, GetHandleSize (CTHandle));
>         }
>     }
> }

The "if (tempRB & 0x4000)" line will always be false. CopyBits looks at that bit and if its set it
dereferences the pixmap _before_ calling the bottleneck bitsProc (oh, and by the way it doesnt HLock
the PixMapHandle first either, so on entry bitPtr could be a pointer to an unlocked, dereferenced
PixMap).

This means that if you call StdBits rather than copybits, you can use a rowbytes value of up to
0x7fff (This was documented once in a technote I think, but is probably unsupported).

- --------------------------------------
Mark Williams<[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Dave M Brosius)
Date: 17 Feb 1996 07:52:34 GMT
Organization: Chester County Internet Services, Inc.

In article <4fl5aq$[e-mail]>, Lawson English
<[e-mail]> wrote:

> Chris De Salvo <[e-mail]> wrote:
> [snipt]
> :    rowBytes = (**(**theGDH).gdPMap).rowBytes & 0x7FFF;
>
> All the working code samples that I have uses 0x3fff, not 0x7fff.
>
>
> Anyone know if it makes any difference in the real world?

Yes!

use 0x3FFF...

I think bit 14 means that no color table mapping occurs... ie source
pixmaps are drawn using the color indexes of the gworlds pixmap.

--
Please reply via email as well
dave [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Sat, 17 Feb 1996 14:35:23 GMT
Organization: Network Analysis Ltd

In article <[e-mail]>,
[e-mail] wrote:

> This means that if you call StdBits rather than copybits, you can use a
> rowbytes value of up to 0x7fff (This was documented once in a technote I
> think, but is probably unsupported).

As an aside, QD will cheerfully let you create pixmaps whose rowBytes are
longer than 0x3fff, but will, er, "behave strangely" you attempt to
CopyBits from such a pixmap. It does seem to let one CopyBits to such a
pixmap though. It's quite easy to generate such a pixmap in PhotoShop: I
was downsampling Scitex CT files, and by mistake the test file that I made
with Photoshop was 72 dpi instead of the 300 dpi that I had intended, and
it killed my appl. I've fixed it now, but it took me ages to work out what
was going on...

--
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!britain.eu.net!nan!sw
Phone: [phone]                              Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Sun, 18 Feb 1996 13:22:16 GMT
Organization: Network Analysis Ltd

In article <[e-mail]>,
[e-mail] (John W. Baxter) wrote:

>    I'm not sure it makes any current real-world difference.  However, the
> value rowBytes is specified as being less than 0x4000 (IM: Imaging with
> QuickDraw, page 4-47), and the top two bits are specified as being used as
> flags.  No use of bit 14 is given on that page (leaving a few other IM

Doesn't CopyBits use it to tell whether you've called LockPixels on the
pixmap? Can't remember where I saw this though, so it might be a figment
of my imagination...

--
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!britain.eu.net!nan!sw
Phone: [phone]                              Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Matt Gough)
Date: Sat, 17 Feb 1996 21:23:09 +0000
Organization: Internet Discovery Ltd

>
>I think bit 14 means that no color table mapping occurs... ie source
>pixmaps are drawn using the color indexes of the gworlds pixmap.
>

Bit 14 tells Qd internally that the pixmap was created for a GWorld, and
that it has to RecoverHandle on the baseAddr to get the real pixmap data.

Matt Gough

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Mon, 19 Feb 96 18:17:05 +0300
Organization: (none)

In article <[e-mail]>,
[e-mail] (Dave M Brosius) wrote:

>I think bit 14 means that no color table mapping occurs... ie source
>pixmaps are drawn using the color indexes of the gworlds pixmap.


In article <[e-mail]>,
[e-mail] (Matt Gough) wrote:

>Bit 14 tells Qd internally that the pixmap was created for a GWorld,
and
>that it has to RecoverHandle on the baseAddr to get the real pixmap
data.


People, please stop this mess. Bit 14 in rowBytes has nothing to do
with color-remapping blocking (ctFlags field of color table does it),
nor with the state of baseAddr block (pmVersion field of PixMap does
it).
RowBytes' bit 14 is only getting used within CopyBits call to
distinguish between color grafports and bitmaps/pixmaps.

BTW, among the list of groups:
comp.sys.mac.graphics, comp.sys.mac.programmer.help,
comp.sys.mac.programmer.games, comp.sys.mac.programmer.tools,
comp.sys.mac.programmer.codewarrior

only comp.sys.mac.programmer.help has to do with the question.
So I removed other groups from news-header.

- --------------------------------------------------------------
Michael Kluev                            [e-mail]
Macintosh Programmer                           Physics Grad, MSU
MACsimum Ltd.                                     Moscow, Russia
- --------------------------------------------------------------

---------------------------

>From [e-mail] (Nolan W. Whitaker)
Subject: PEF (Preferred Executable Format) Info Needed
Date: Sun, 11 Feb 1996 01:53:07 GMT
Organization: IgLou Internet Services (1-800-436-4456)

I have been desperately searching for documentation on the
Preferred Executable Format used for binary files on the Mac
and the BeBox.

I assumed that Inside Macintosh would document this thoroughly,
but the only reference I could find on my Inside Mac CD was a
brief note in the PowerPC Systems book that stated essentially
that Macs use PEF--- but no explanation or examples of the
format.

I've also searched the Web using a couple of different search
engines without finding anything useful.

I will be beginning a project for the BeBox very soon where I'll
need to produce an executable file, but in order to due that
I need to find a detailed explanation of the file format.

Any ideas?  Is this info available on any of the Apple developer
CDs?  A book?


Thanks,
Nolan


======================================================================
=  [e-mail]          ||                                      =
=  [e-mail]        ||     http://www.ewl.uky.edu/~nolanw   =
======================================================================
= ...waiting on that BeBox I ordered to arrive...                    =
======================================================================


+++++++++++++++++++++++++++

>From [e-mail] (Fred Fish)
Date: 13 Feb 1996 17:53:42 GMT
Organization: Cronus

In article <[e-mail]>,
Eric M. Kidd <[e-mail]> wrote:
>It seems, according to statements from MWRon, that PEF is a fairly
>well-guarded Apple patent, with licensing agreements and whatnot. This
>brings up a couple of issues.

What is the patent number please.

>   * How are folks supposed to make GNU tools work on the PowerMac?

My understanding is that the MacOS loads XCOFF as well as PEF, and
that the current port of gcc to MacOS generates XCOFF executables.

>   * How are folks supposed to make GNU tools work on the BeBox?

There are a number of possibilities for getting a gcc port that just
compiles posix type apps (getting a full g++ port for doing Be
specific things is much harder):

(1)    Add PEF support to the BFD library so that the linker
    can generate PEF executables.  Note that it isn't necessary
    that the intermediate object files be PEF, though that would
    probably not be much more work to implement.  This will require
    either having Apple become more open about supplying documentation
    on PEF without restriction, or reverse engineering the PEF format.
    I have a document that was written by someone who did just that,
    but I don't know how complete it is, with regards to being suitable
    for adding PEF support to the BFD library.

(2)    Use an XCOFF (or ELF) to PEF translator to convert the output
    of the linker to PEF format.  For maximum compatibility this would
    have to be done by someone with access to the PEF documentation
    under NDA.  They could then distribute BeOS binaries or possibly
    other binaries like linux, for those that are interested in
    initially building GNU cross environments to help in bootstrapping
    all the utilities to BeOS.  One problem here is that we would need
    a reverse PEF to XCOFF translator to generate BeOS libraries
    that the GNU linker can use.  Aside from being somewhat of
    a kludge, it this solution doesn't help for things like gdb
    ports, where the program has to be able to read the native
    executable format unless you want to keep both the XCOFF and
    PEF versions of each executable and attach to the running
    PEF version while reading symbols and such out of the XCOFF
    version.

(3)    Have gcc produce assembly files that are then fed to the
    current Metroworks tools for assembly and linkage.  This is
    somewhat how early SVR4 gcc ports worked before the GNU tools
    fully supported ELF format.

(4)    If you just want ports of "GNU tools" but not necessarily
    gcc, then use the existing tools to build the GNU tools, as
    many people are already doing.  Ideally the posix environment
    on BeOS needs to be as complete as possible, and this is
    currently being worked on AFAIK.  Simple things already work,
    and some tools like sed compile almost unchanged.  However
    other tools that depend heavily on things like signals,
    fork/exec, etc will take much more work with the current
    release.

(5)    There must be at least a couple other solutions :-)

-Fred
--
CRONUS  --  1840 E. Warner Road #105-265  --  Tempe, AZ 85284  --  USA
Voice:  [phone]  or  [phone]        FAX:  [phone]
Email:  [e-mail]  or  [e-mail] (coming soon)
Ftp site: ftp.amigalib.com  or  ftp.ninemoons.com (coming soon)

+++++++++++++++++++++++++++

>From [e-mail] (C.K. Haun)
Date: Tue, 13 Feb 1996 11:38:47 -0800
Organization: Be, Inc.

In article <[e-mail]>, [e-mail] (Nolan W. Whitaker) wrote:
> I have been desperately searching for documentation on the
> Preferred Executable Format used for binary files on the Mac
The PEF format is proprietary to Apple and IBM, we are using it under
license from Apple.
It's not documented anywhere, except for some freeware documentation that
someone reverse-engineered and posted here and there (I actually don't
know where) and even that is not complete.
Tools developers can license the format information from Apple, and when
we finalized our licensing agreement with Apple we will be able to
sub-license to our developers.

Why is it so secret?  Dont' really know, but it's the rules we have to play by.

C.K. Haun <TR>
The Developer Guy @ Be, Inc.                 [e-mail]
                          The Mild Bunch
1996 Royal Star 1300    1991 Voyager 1200    1990 Virago 750
1993 Virago 535         1987 Reflex 225      <maybe a Valkirie soon?>

+++++++++++++++++++++++++++

>From [e-mail] (Eric M. Kidd)
Date: Tue, 13 Feb 1996 11:34:12 -0500
Organization: Dartmouth College

In article <[e-mail]>, [e-mail] (Nolan W. Whitaker) wrote:

> I have been desperately searching for documentation on the
> Preferred Executable Format used for binary files on the Mac
> and the BeBox.
>
> I assumed that Inside Macintosh would document this thoroughly,
> but the only reference I could find on my Inside Mac CD was a
> brief note in the PowerPC Systems book that stated essentially
> that Macs use PEF--- but no explanation or examples of the
> format.

It seems, according to statements from MWRon, that PEF is a fairly
well-guarded Apple patent, with licensing agreements and whatnot. This
brings up a couple of issues.

   * How are folks supposed to make GNU tools work on the PowerMac?
   * How are folks supposed to make GNU tools work on the BeBox?

Just wondering. =)

(This article is cross-posted, by the way. Please reset followups if it's
about to get off topic in either newsgroup.)

Cheers,
Eric

........................................................................
Eric Kidd ([e-mail])      http://coos.dartmouth.edu/~emk/
"Computers are useless.  They can only give you answers." -Pablo Picasso

+++++++++++++++++++++++++++

>From [e-mail] (Fred Fish)
Date: 13 Feb 1996 20:18:37 GMT
Organization: Cronus

In article <[e-mail]>, C.K. Haun <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] (Nolan W. Whitaker) wrote:
>Tools developers can license the format information from Apple, and when
>we finalized our licensing agreement with Apple we will be able to
>sub-license to our developers.

Neither of these will help the people wanting to provide support for
GNU tools on the BeBox unless the licensing explicitly allows
releasing source code that makes use of information provided under the
license agreement.

-Fred

--
CRONUS  --  1840 E. Warner Road #105-265  --  Tempe, AZ 85284  --  USA
Voice:  [phone]  or  [phone]        FAX:  [phone]
Email:  [e-mail]  or  [e-mail] (coming soon)
Ftp site: ftp.amigalib.com  or  ftp.ninemoons.com (coming soon)

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 14 Feb 1996 01:01:43 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <4fqj76$[e-mail]> [e-mail] (Fred Fish) writes:
)
) My understanding is that the MacOS loads XCOFF as well as PEF, and
) that the current port of gcc to MacOS generates XCOFF executables.

I can't get it to load an XCOFF executable, but there may be some magic
incantation needed that I'm unaware of.

) (1)    Add PEF support to the BFD library so that the linker
)     can generate PEF executables.  Note that it isn't necessary
)     that the intermediate object files be PEF, though that would
)     probably not be much more work to implement.

PEF is not suitable for intermediate object files.


/Bo Lindbergh

+++++++++++++++++++++++++++

>From [e-mail] (Jay Farrell)
Date: Wed, 14 Feb 1996 00:32:11 -0500
Organization: Jayfar's Web

In article <4fqrmt$[e-mail]>, [e-mail]
(Fred Fish) wrote:

> In article <[e-mail]>, C.K. Haun <[e-mail]> wrote:
> >In article <[e-mail]>, [e-mail] (Nolan W. Whitaker)
wrote:
> >Tools developers can license the format information from Apple, and when
> >we finalized our licensing agreement with Apple we will be able to
> >sub-license to our developers.
>
> Neither of these will help the people wanting to provide support for
> GNU tools on the BeBox unless the licensing explicitly allows
> releasing source code that makes use of information provided under the
> license agreement.

Damn.  Is this yet another instance of Apple leaving P.D. language
developers out in the cold?

This same sort of situation appears to exist with OpenDoc.  Although
Apple's OpenDoc Programmers Guide states that OpenDoc parts can be written
in any language, there are no IDL emitters to accommodate this AFAIK.

Bring back Wozniak and put him in charge of R&D -- he'd kill all this secrecy.

Cheers,
Jayfar

   /////////////////////////////////////////////////////////////////////////////
  ////// The Mops Page    <URL:http://www.netaxs.com/~jayfar/mops.html>  //////
 /////////////////////////////////////////////////////////////////////////////
 Jay Farrell
 [e-mail]                       <URL:http://www.netaxs.com/~jayfar/>
 Philadelphia, Pennsylvania, USA           Jayfar's Virtual Mac FTP Site

+++++++++++++++++++++++++++

>From [e-mail] (Nolan W. Whitaker)
Date: Wed, 14 Feb 1996 15:59:28 GMT
Organization: IgLou Internet Services (1-800-436-4456)

[e-mail] (Fred Fish) wrote:

>There are a number of possibilities for getting a gcc port that just
>compiles posix type apps (getting a full g++ port for doing Be
>specific things is much harder):

...misc deleted

>(3)    Have gcc produce assembly files that are then fed to the
>    current Metroworks tools for assembly and linkage.  This is
>    somewhat how early SVR4 gcc ports worked before the GNU tools
>    fully supported ELF format.


This is essentially what I think I'll be doing with at least one
of my projects.  As long as Be continues shipping a copy of the
Metrowerks stuff with every machine and they don't change
things too much, I think I'll be reasonably ok.

Thanks for all the info guys!
-Nolan


======================================================================
=  [e-mail]          ||                                      =
=  [e-mail]        ||     http://www.ewl.uky.edu/~nolanw   =
======================================================================
= ...waiting on that BeBox I ordered to arrive...                    =
======================================================================


+++++++++++++++++++++++++++

>From [e-mail] (Fred Fish)
Date: 14 Feb 1996 16:05:45 GMT
Organization: Cronus

In article <4frc9n$[e-mail]>,
Bo Lindbergh <[e-mail]> wrote:
>
>PEF is not suitable for intermediate object files.

Now that's interesting!  I haven't examined the meager documentation I
have on PEF yet in any detail, so I wasn't aware of that.  I just
assumed that since it was an XCOFF derivative, which is typically used
for both the object and executable format, that it was the same for
PEF.

So that leads up to the question, what *is* the object file format
that the MetroWerks compiler uses?  Does this mean that if anyone
wants to produce a fully compatible set of GNU tools that they not
only have to deal with an undocumented object file format, they also
have to deal with a (different) undocumented object file format and an
undocumented library format?

Gee, standard ELF objects/executables and standard unix style "ar"
archives are sure starting to sound like a more appropriate longterm
solution for what is being promoted as a hackers machine.  :-)

-Fred
--
CRONUS  --  1840 E. Warner Road #105-265  --  Tempe, AZ 85284  --  USA
Voice:  [phone]  or  [phone]        FAX:  [phone]
Email:  [e-mail]  or  [e-mail] (coming soon)
Ftp site: ftp.amigalib.com  or  ftp.ninemoons.com (coming soon)

+++++++++++++++++++++++++++

>From [e-mail] (Benoit Triquet)
Date: 14 Feb 1996 22:13:12 GMT
Organization: SUPELEC

Fred Fish ([e-mail]) wrote:
: So that leads up to the question, what *is* the object file format
: that the MetroWerks compiler uses?  Does this mean that if anyone
: wants to produce a fully compatible set of GNU tools that they not
: only have to deal with an undocumented object file format, they also
: have to deal with a (different) undocumented object file format and an
: undocumented library format?

hd (/bin/hd on the bebox, hex dump) any .o file. you read MWOBPPC
*WIN* the object format is a metrowerks thing.
This story with PEF is becoming unpleasant... Our hacker open minded $50
licensing machine has it in the...
Hey btw, JLG, how do you intend to deal with PEF in the $50 license fee for
the BeOS ??

Benoit

+++++++++++++++++++++++++++

>From [e-mail] (Al Kossow)
Date: 14 Feb 1996 17:49:21 -0800
Organization: Internet Wiretap

>From article <4ftmpo$[e-mail]>, by [e-mail] (Benoit Triquet):
> Hey btw, JLG, how do you intend to deal with PEF in the $50 license fee for
> the BeOS ??
>

Has anyone tried contacting Apple about dropping the PEF license? I would think
now would be a good time to try, given the current push to open up other parts
of the system.


+++++++++++++++++++++++++++

>From Mike Griebling <grieblm@es2>
Date: 15 Feb 1996 12:10:47 GMT
Organization: AlliedSignal Engines, Phoenix, Az

Fred Fish writes:

> In article <4frc9n$[e-mail]>,
> Bo Lindbergh <[e-mail]> wrote:
> >
> >PEF is not suitable for intermediate object files.
>
> So that leads up to the question, what *is* the object file format
> that the MetroWerks compiler uses?  Does this mean that if anyone
> wants to produce a fully compatible set of GNU tools that they not
> only have to deal with an undocumented object file format, they also
> have to deal with a (different) undocumented object file format and an
> undocumented library format?

Good question!  Anyone at Be care to comment?

> Gee, standard ELF objects/executables and standard unix style "ar"
> archives are sure starting to sound like a more appropriate longterm
> solution for what is being promoted as a hackers machine.  :-)

I agree 100%!

> -Fred


Regards,
    Michael
- ------------------------------------------------------------
Michael Griebling, P. Eng.        [e-mail]
Computer Inspirations            [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jon Watte)
Date: Thu, 15 Feb 1996 19:16:47 -0600
Organization: Rudimentary


In article <4ft18p$[e-mail]>,
[e-mail] (Fred Fish) wrote:

> assumed that since it was an XCOFF derivative, which is typically used
> for both the object and executable format, that it was the same for
> PEF.

PEF was invented by Apple because it is SUBSTANTIALLY more compact than
XCOFF. Part of what makes it compact is the patented relocation mechanism.
Part is all the "unnecessary" stuff they left out...

However, PEF is still pretty flexible; you might for instance add some kind
of external data (like application resources) to a PEF section without
breaking tools that don't know about this special section.

> So that leads up to the question, what *is* the object file format
> that the MetroWerks compiler uses?  Does this mean that if anyone

The file type is "MPLF" which stands for the Metrowerks Preferred Link
Format. It is geared towards supporting features of our development tools
such as fast linking and good symbolics support. However, as we strive to
improve the performance of our tools, we may change this format, even
though it's been still for a long time now. What HAS changed is the
requirements for runtime support glue, that's why some older libraries will
not link with newly compiled applications.

> wants to produce a fully compatible set of GNU tools that they not
> only have to deal with an undocumented object file format, they also
> have to deal with a (different) undocumented object file format and an
> undocumented library format?

If you're serious, we will most definately talk to you. We are working
closely with several vendors on the Mac side who write compiler plug-ins
for the IDE. Please talk to me in e-mail and I will forward your request if
needed.

Cheers,

                            / h+


--
 Jon Watte, Austin, TX
 Play: [e-mail]; Work: [e-mail]

 "It's a joke, dammit!"


+++++++++++++++++++++++++++

>From [e-mail] (Mike Duigou)
Date: Sun, 18 Feb 1996 14:33:37 -0800
Organization: FWB Inc.

In article <[e-mail]>,
[e-mail] (Jay Farrell) wrote:

...
>
>Damn.  Is this yet another instance of Apple leaving P.D. language
>developers out in the cold?
>
>This same sort of situation appears to exist with OpenDoc.  Although
>Apple's OpenDoc Programmers Guide states that OpenDoc parts can be written
>in any language, there are no IDL emitters to accommodate this AFAIK.
>
>Bring back Wozniak and put him in charge of R&D -- he'd kill all this secrecy.
>
...

It occurs to me that most of this discussion is continuing on the basis of
inuendo, rumor and suspicion, and not a whole lot on facts. Has anyone
actually contacted Apple liscencing? I have yet to see anyone quote
coorespondance from an Apple response which confirms or denys the alleged
behaviour. One would assume that their respone would be the only thing
that matters. Incidentally you can contact Apple liscencing at :

   mailto:[e-mail]
   http://dev.info.apple.com/swl/swl.html

Come on, this issue has been going on for weeks on the various Mac
programming news groups with no new information being injected into the
discussion. The general impression left is that its just a bunch of crabby
malcontents bitching about Apple and the supposed subject matter (PEF file
format) is not really the issue.

Mike Duigou
FWB Inc.
--
"Me, when I have nothing to say, my lips are sealed." -- Talking Heads

---------------------------

>From [e-mail] (Peter Hoebel)
Subject: Reconnecting Mounted Appleshare Volumes
Date: 20 Feb 1996 05:58:20 GMT
Organization: Teranet IA Inc

    Greetings.

    I've got three related network issues I need help with.  The first two
are of a lower priority.  The situation is this.  In an appletalk zone one
Mac mounts four other Macs.  When one of these four shuts down the
first mac displays the usual "the server ... has been unexpectedly
shutdown at ..." dialog.  Our application on the first Mac regularly
copies files from the four mounted Macs.  We're running 7.5.1.

1) Is there anyway to disable this message from even
appearing or automatically emulating a return key being pressed if it is
displayed?

2) Is there anyway to change the default timeout time, it's approximately
2 minutes in our LAN?

3)  The initial mac needs to reconnect to the shutdown mac after it
restarts which we're assuming is almost right away.

This third question is the most important one.
I believe one approach would be to resolve an alias to the volume, such
as is stored in recent servers.  More complicated would be to store an alias
record of the volume when it first is mounted and then resolve it after
it has rebooted.  Is there anyway to reconnect without having to manage
an alias in our code?

Any guidance would be most welcome.

                Many thanks,
                    Pete Hoebel

                [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 20 Feb 1996 02:59:20 -0500
Organization: America Online, Inc. (1-800-827-6364)

> I've got three related network issues I need help with.  The
>first two  are of a lower priority.  The situation is this.  In
>an appletalk zone one  Mac mounts four other Macs.  When one of
>these four shuts down the  first mac displays the usual "the
>server ... has been unexpectedly  shutdown at ..." dialog.  Our
>application on the first Mac regularly  copies files from the
>four mounted Macs.  We're running 7.5.1.
>
>1) Is there anyway to disable this message from even  appearing
>or automatically emulating a return key being pressed if it is
>displayed?

Get the AppleShareSetup control panel from Apple (I wrote it). It lets you
disable some or all of the dialogs the AppleShare client puts up. Or, you
can let them come up, but time out after a specified amount of time.
AppleShareSetup is available on most major online services and from
Apple's ftp server.

>2) Is there anyway to change the default timeout time, it's
>approximately  2 minutes in our LAN?

There's really no good way to change that. The time-out is handled by the
.XPP driver's ASP/AFP protocol stack and the ASP specification says the
time-out for sessions is two minutes.

I guess you could use PConfirmName to see if the server is still
responding to directed NBP lookups and if it doesn't respond within a
certain amount of time, you could kill the ASP session with
ASPCloseSession. I wrote a Macintosh Tech Note that tells how to get the
AFP/ASP session reference number a few years ago. You should be able to
find it in the Network Tech Notes at
<http://dev.info.apple.com/technotes/Archive/Main_archive.html>. This
technique is rather rude though.

>3)  The initial mac needs to reconnect to the shutdown mac after
>it  restarts which we're assuming is almost right away.

You can reconnect by either resolving an alias to the server, or by using
the File Manager's PBVolumeMount function. You'll have to take care of
that from your own code.

- Jim Luther

---------------------------

>From 'Digital Dave' Shields <[e-mail]>
Subject: Stuck in a bottleneck
Date: Sun, 11 Feb 1996 21:56:16 -0800
Organization: Vanguard Vision Studios, San Francisco, CA

I have created some special PICT files with data stored in each file's
Pic Comment field. In order to parse the data, I have installed a
CQDProc bottleneck procedure in my code. The procedure is being called
fine.

My problem is the bottleneck procedure needs to communicate with the
rest of the code by setting application globals. The bottleneck
procedure is a callBack routine, and I don't have access to application
globals without setting up and restoring the A4 register (under Think C
it's A4 not A5).

Since the bottleneck procedure doesn't include a reference constant
field as one of its arguments, I cannot pass the address of the
application's A4 to the bottleneck proc in order to do this.

Any suggestions?

--Dave

+++++++++++++++++++++++++++

>From [e-mail] (MonHacker)
Date: 12 Feb 1996 13:12:24 -0500
Organization: America Online, Inc. (1-800-827-6364)


<<
Any suggestions?
>>

Have you considered making your own OS queue?

Bob Boylan

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 12 Feb 1996 20:06:14 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] writes:
>My problem is the bottleneck procedure needs to communicate with the
>rest of the code by setting application globals. The bottleneck
>procedure is a callBack routine, and I don't have access to application
>globals without setting up and restoring the A4 register (under Think C
>it's A4 not A5).

Bottlenecks have full access to application globals. Unless you are writing
a code resource instead of a full application, the register is A5 just
like in all other environments.

>Since the bottleneck procedure doesn't include a reference constant
>field as one of its arguments, I cannot pass the address of the
>application's A4 to the bottleneck proc in order to do this.

If you need to do something like this, the usual procedure is to append
a field to the structure that is passed to the callback. In this case you
could add a field to the CGrafPort (allocate it yourself, of course) and
set it to A5. Fortunately it is not needed in this case.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From 'Digital Dave' Shields <[e-mail]>
Date: Mon, 12 Feb 1996 20:11:14 -0800
Organization: Vanguard Vision Studios, San Francisco, CA

MonHacker wrote:
>
> Have you considered making your own OS queue?

I thought a Bottleneck procedure was called at "interrupt time". Is this
not true?

If so, that would mean one could not move memory. In a message queue
structure, you have to allocate an object on the heap and add it in...or
is there another way to set up a queue for this purpose?

--Dave

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 13 Feb 1996 10:58:57 GMT
Organization: Ecole Normale Superieure, Paris, France

In article <[e-mail]>,
'Digital Dave' Shields  <[e-mail]> wrote:

>I thought a Bottleneck procedure was called at "interrupt time". Is this
>not true?

Although Juri has already said it, I will reiterate to clear some
misconceptions: if you are writing an application, your globals can be
accessed (off the A5 register) without needing to do anything special
in your bottleneck. Bottlenecks are not called at interrupt time; they
are called by DrawPicture and they are free to move memory, write into
global variables. I guess the only thing they can't do (unless you know
what you're doing) is to make QuickDraw calls.


--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 14 Feb 1996 00:39:51 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] writes:
>MonHacker wrote:
>>
>> Have you considered making your own OS queue?
>
>I thought a Bottleneck procedure was called at "interrupt time". Is this
>not true?

It is not true. QD Bottlenecks are called from within QuickDraw. QuickDraw
may not be called from within interrupts. Thus, QD bottlenecks may move memory
and do just about anything you want.

>If so, that would mean one could not move memory. In a message queue
>structure, you have to allocate an object on the heap and add it in...or
>is there another way to set up a queue for this purpose?

OS Queues are useful because Enqueue and Dequeue disable interrupts
during critical sections so that you can access the queues from within
interrupts without having to worry about a non-interrupt level routine
being in the middle of changing the queue structure.

In this particular case, I don't see how they could be useful.

The normal procedure is that the queue entry is something like a
parameter block and the block is owned by the queue until it is
no longer needed. (If you call PBRead asynchronously, the parameter
block is reserved until the read completes.)

If you need to enqueue stuff from an interrupt level, you have to
preallocate the entries. The best way to do this is to allocate a
chunk of memory at startup and then enqueue entries from this
memory. When you need a block, you dequeue from the queue. When
the block is released, you enqueue it back into your free queue.

But, as I said, OS queues have very little to do with QD bottlenecks.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Dave M Brosius)
Date: 17 Feb 1996 08:19:37 GMT
Organization: Chester County Internet Services, Inc.

In article <4fpqth$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <[e-mail]>,
> 'Digital Dave' Shields  <[e-mail]> wrote:
>
Bottlenecks are not called at interrupt time; they
> are called by DrawPicture and they are free to move memory, write into
> global variables. I guess the only thing they can't do (unless you know
> what you're doing) is to make QuickDraw calls.


You can however call the Stdxxxx forms of quickdraw calls.

--
Please reply via email as well
dave [e-mail]

---------------------------

>From [e-mail] (Matthew Xavier Mora)
Subject: USENET Macintosh Programming Awards (UMPA)
Date: Fri, 16 Feb 1996 17:57:22 GMT
Organization: MXM Designs


Announcing The Second Annual USENET Macintosh Programming Awards
                           UMPA 1996

It is now time to start nominating this years programmers. Below is
the article I sent out to the c.s.m.p.* newsgroups to start the
nomination process. Since I sent out that article Bare Bones Software
and Metrowerks said that they would sponsor this years event. Cool!

We have been getting a lot of prizes thanks to some evanglizing from
Jordan Mattson. Thanks Jordan.

So the list of prizes so far is:

 Every winner will get this stuff:
 - UMPA T -Shirt
 - UMPA Plaque.
 - $100.00 Cash Prize  (Oooh!)
 - $100.00 APDA Gift Certificate (from Juan Bettaglio )
 - A Self Paced Course from DU (from Jennifer Martin)
 - One years free membership in the Associates Plus or AMP program
   ( Or an extension if currently enrolled from Cindy Gallie)

The things below will go to the winners of the ShareWare, Freeware,
Support and Smart friend categories only since the Commercial winner
has all this stuff anyway.

 - Lots o' Symantec Stuff (includes Mac C++ and Java tools)
    (from Will Iverson)
    t-shirts, option for any Symantec product NFR
    (e.g. a choice of C++ Win, ACT!, Norton, etc.).
 - Apprentice CD (From Paul Celestin )

 - BBEdit and BBEdit T-shirts (From Rich Siegel)
 - Metrowerks Gold CD
 - QC from Devon Hubbard
 - Roaster the Java Development Environment from  Natural Intelligence


A big thanks to our sponsors!

So send in your nominations!

Matt

- -----------------------------------------------------------
U M P A
- -----------------------------------------------------------

It looks like its time for the Second Annual Usenet Macintosh
Programming Awards (UMPA). For those of you that have never heard of
this before, last year we created the UMPA awards to honor our peers
in the Mac Programming world. Often a program itself will get awarded
but the person(s) responsible for creating the product never get their
due recognition for a job well done. This award is to honor those in
the trenches fighting the good fight for the Macintosh.

I would like to start the nomination process now and have it go until
the end of March. (Prizes determined by the number of vendors willing
to donate prizes)

Here is a list of the categories. The five categories are:

       Outstanding Programming for a Commercial Product.

       Outstanding Programming for a Shareware Product.

       Outstanding Programming for a Freeware Product

       Outstanding Support of the Mac programming community.
       (usually from a non programmer)

       Official SmartFriend(tm) award for the most helpful c.s.m.p.* net
citizen.


Here is a list of the current nominees (Remember we are nominating the
programmers not the product so please include the name of the
programmer(s)):


Outstanding Programming for a Commercial Product:
    1. Rich Siegel for BBEdit
    2. Jordan Zimmerman for QuickView/MPTA
    3. OneClick (WestCode Software)

Outstanding Programming for a Shareware Product:
    1. Peter Lewis for Net Presenz

Outstanding Programming for a Freeware Product:
    1. Michael Hecht for ResCompare
    2. Steve Dagley, Richard Reynolds, and Co. for FreePPP.
    3. Lindsay Davies and Carles Bellver for HTML tools for BBEdit

Outstanding Support of the Mac programming community:
    1. The folks at MetroWerks
    2. Neil Ticktin of MacTech Magazine

Official SmartFriend(tm) award :
    1. Jon Pugh, for many of his insights on AppleScript


The list of final nominees is chosen by the number times that
programmer was nominated. So if you want your favorite programmer
to make the nomination cut, Send in his/her name.

Since this award is supposed to be recognition from our peers, You
will need to answer a Macintosh programming question to have a valid
nomination.

The first question is:

What is the recommended sleep value for WaitNextEvent for a foreground
Application. :-)


So send me your nominations <mailto:[e-mail]> with what you
"think" is the correct answer to the above question and I will keep
updating the nomination list. I will set up a web page for this when
ever I can remember my password to my shell account.

If you would like to donate prizes to this cause, please send me email
<mailto:[e-mail]>. Last year we collected 5 prizes for each
category. This year I think we should just collect 4 prizes since the
"Outstanding Programming for a Commercial Product" winner already had
all the stuff we collected last year. The award,t-shirt and plaque cash
and other goodies is probably honor enough.

Thanks for listening and good luck to the nominees!


Xavier

--
Matthew Xavier Mora
Developer Technical Support
Apple Computer, Inc.                                         [e-mail]

---------------------------

>From [e-mail] (MystryMan)
Subject: [Q] NURBs and lighting
Date: 30 Jan 1996 14:17:58 -0800
Organization: Teleport - Portland's Public Access [phone]

Can anyone explain why when my camera is at ( 0 0 200 ) looking to ( 0 0 0 )
and my pointlight is at ( 0 0 -200 ), I see half the sphere colored in RED?

It seems to me that since the light on the opposite side of the sphere (as
compared to the camera), the side of the sphere I am viewing through the camera
should be black (I have no ambient light).

What am I missing?  It's probably something obvious, but I don't see it.

Since I know other people are interested in seeing an example of a NURB sphere
using QD3D, I am posting the entire metafile (it's small).



3DMetafile ( 1 0 Normal tableofcontents0> )
  viewhints2:
  Container (
    ViewHints ( )
    interactiverenderer3:
    Container (
      InteractiveRenderer ( )
      InteractiveDoubleBufferBypass ( True )
    )
    viewangleaspectcamera4:
    Container (
      ViewAngleAspectCamera ( 0.8726646 1 )
      CameraPlacement (
        0 0 200 # location
        0 0 0 # point of interest
        0 1 0 # up vector
      )
      CameraRange ( 0.1 500 )
      CameraViewPort ( -1 1 2 2 )
    )
    pointlight5:
    Container (
      PointLight (
        0 0 -200 # location
        0 0 0 # attenuation
        False # castsShadows
      )
      LightData ( True # isOn
        1 # brightness
        1 0 0 # color
      )
    )
    attributeset6:
    Container (
      AttributeSet ( )
      AmbientCoefficient ( 1 )
      DiffuseColor ( 0.5 0.5 0.5 )
      SpecularColor ( 0.5 0.5 0.5 )
      SpecularControl ( 4 )
      TransparencyColor ( 1 1 1 )
    )
    ImageClearColor ( 0 0 1 0 )
    ImageDimensions ( 300 300 )
  )
  phongillumination7:
  PhongIllumination ( )
  interpolationstyle8:
  InterpolationStyle ( Pixel )
  backfacingstyle9:
  BackfacingStyle ( Both )
  fillstyle10:
  FillStyle ( Filled )
  ordereddisplaygroup11:
  BeginGroup (
    OrderedDisplayGroup ( )
  )
  scale12:
  Scale ( 75 75 75 )
  nurbpatch13:
  Container (
    NURBPatch (
      3 3 # uOrder, vOrder
      5 9 # numRows, numColumns
      0 -1 0 1
      0 -0.707107 0 0.707107
      0 -1 0 1
      0 -0.707107 0 0.707107
      0 -1 0 1
      0 -0.707107 0 0.707107
      0 -1 0 1
      0 -0.707107 0 0.707107
      0 -1 0 1
      0.707107 -0.707107 0 0.707107
      0.5 -0.5 0.5 0.5
      0 -0.707107 0.707107 0.707107
      -0.5 -0.5 0.5 0.5
      -0.707107 -0.707107 0 0.707107
      -0.5 -0.5 -0.5 0.5
      0 -0.707107 -0.707107 0.707107
      0.5 -0.5 -0.5 0.5
      0.707107 -0.707107 0 0.707107
      1 0 0 1
      0.707107 0 0.707107 0.707107
      0 0 1 1
      -0.707107 0 0.707107 0.707107
      -1 0 0 1
      -0.707107 0 -0.707107 0.707107
      0 0 -1 1
      0.707107 0 -0.707107 0.707107
      1 0 0 1
      0.707107 0.707107 0 0.707107
      0.5 0.5 0.5 0.5
      0 0.707107 0.707107 0.707107
      -0.5 0.5 0.5 0.5
      -0.707107 0.707107 0 0.707107
      -0.5 0.5 -0.5 0.5
      0 0.707107 -0.707107 0.707107
      0.5 0.5 -0.5 0.5
      0.707107 0.707107 0 0.707107
      0 1 0 1
      0 0.707107 0 0.707107
      0 1 0 1
      0 0.707107 0 0.707107
      0 1 0 1
      0 0.707107 0 0.707107
      0 1 0 1
      0 0.707107 0 0.707107
      0 1 0 1
      0 0 0 1 1 2 2 3 3 4 4 4 # uKnots
      0 0 0 1 1 2 2 2 # vKnots
    )
    attributeset14:
    Container (
      AttributeSet ( )
      AmbientCoefficient ( 1 )
      DiffuseColor ( 1 1 1 )
      SpecularColor ( 1 1 1 )
      SpecularControl ( 4 )
    )
  )
  EndGroup ( )



===Eric Gorr=================[e-mail]=================aka MystryMan===
_____            *  http://www.teleport.com/~ericg *
|\ /| * Invincibility is in oneself, vulnerability is in the opponent
| O | * Therefore the considerations of the intelligent always include both
|/_\|   benefit and harm (Sun Tzu)

#include <standard.disclaimer>
=====Insults, like violence, are the last resort of the incompetent...=====


+++++++++++++++++++++++++++

>From [e-mail] (MystryMan)
Date: 31 Jan 1996 17:56:53 -0800
Organization: Teleport - Portland's Public Access [phone]

I have been able to get the correct side of the sphere lighted...but I
don't understand *why*.

By changing the backfacing style to kQ3BackfacingStyleFlip, the correct
part of the sphere is now lit.

When my object is not transparent, etc., why would the backfacing style
cause the opposite part of the sphere (in relation to the location of the
light) to be lit?

I find this very odd.



===Eric Gorr=================[e-mail]=================aka MystryMan===
_____            *  http://www.teleport.com/~ericg *
|\ /| * Invincibility is in oneself, vulnerability is in the opponent
| O | * Therefore the considerations of the intelligent always include both
|/_\|   benefit and harm (Sun Tzu)

#include <standard.disclaimer>
=====Insults, like violence, are the last resort of the incompetent...=====


+++++++++++++++++++++++++++

>From Pablo Fernicola <[e-mail]>
Date: Sun, 4 Feb 1996 21:51:33 GMT
Organization: Apple Computer, Inc.

In article <4ep6l6$[e-mail]> MystryMan, [e-mail]
writes:
>I have been able to get the correct side of the sphere lighted...but I
>don't understand *why*.
>
>By changing the backfacing style to kQ3BackfacingStyleFlip, the correct
>part of the sphere is now lit.

Sounds like your patch is inside out.

-Pablo
>Pablo Fernicola- [e-mail]  -QuickDraw 3D Tech Lead
- --- This posting represents my personal opinions.-----
- ---    I do not represent/speak for my employer.   -----

+++++++++++++++++++++++++++

>From [e-mail] (Vanessa Williams)
Date: Thu, 08 Feb 1996 15:45:29 -0500
Organization: Tessera Solutions

In article <[e-mail]>, Pablo Fernicola
<[e-mail]> wrote:

> In article <4ep6l6$[e-mail]> MystryMan, [e-mail]
> writes:
>
> >By changing the backfacing style to kQ3BackfacingStyleFlip, the correct
> >part of the sphere is now lit.
>
> Sounds like your patch is inside out.

What would one have to do wrong in order to create an inside-out patch?

> -Pablo
> >Pablo Fernicola- [e-mail]  -QuickDraw 3D Tech Lead
> ----- This posting represents my personal opinions.-----
> -----    I do not represent/speak for my employer.   -----

+++++++++++++++++++++++++++

>From [e-mail] (MystryMan)
Date: 9 Feb 1996 11:46:27 -0800
Organization: Teleport - Portland's Public Access [phone]

In article <[e-mail]>,
Pablo Fernicola  <[e-mail]> wrote:
>In article <4ep6l6$[e-mail]> MystryMan, [e-mail]
>writes:
>>I have been able to get the correct side of the sphere lighted...but I
>>don't understand *why*.
>>
>>By changing the backfacing style to kQ3BackfacingStyleFlip, the correct
>>part of the sphere is now lit.
>
>Sounds like your patch is inside out.

Why should this matter?  Why would something seem to be lighted when the light
source is on the opposite side?  Or is this just the way lighting works?


===Eric Gorr=================[e-mail]=================aka MystryMan===
_____            *  http://www.teleport.com/~ericg *
|\ /| * Invincibility is in oneself, vulnerability is in the opponent
| O | * Therefore the considerations of the intelligent always include both
|/_\|   benefit and harm (Sun Tzu)

#include <standard.disclaimer>
=====Insults, like violence, are the last resort of the incompetent...=====


+++++++++++++++++++++++++++

>From Pablo Fernicola <[e-mail]>
Date: Sat, 10 Feb 1996 01:53:47 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Vanessa
Williams, [e-mail] writes:
>What would one have to do wrong in order to create an inside-out patch?

Here is the answer from Philip Schneider, our NURB specialist:

The best way to explain how a NURB patch is properly "formatted" is to
show an example of one in "canonical" position.

The various fields of the TQ3NURBPatchData data structure must
be set up correctly with respect to this, in terms of what the
various fields are, how many knots one has, and the ordering of
the control points.

Here's the data structure:

typedef struct TQ3NURBPatchData {
    unsigned long                            uOrder;
    unsigned long                            vOrder;
    unsigned long                            numRows;
    unsigned long                            numColumns;
    TQ3RationalPoint4D           *controlPoints;
    float                                       *uKnots;
    float                                       *vKnots;
    unsigned long                            numTrimLoops;
    TQ3NURBPatchTrimLoopData        *trimLoops;
    TQ3AttributeSet                          patchAttributeSet;
} TQ3NURBPatchData;

Consider a bicubic NURB patch that is facing you, and has
5 control points in the U direction,  and 4 control points
in the V direction. Conceptually, a NURB patch's control points are
a 2-dimensional array of points; of course, we have to represent
this as a list of points in C when we pass them into the NURB
drawing routine. So, one has to make sure that the points are
listed in the order in which QD3D expectsthem. That order is as
follows:

1. The first control point is at the lower left corner.
2. The bottom row, corresponding to the U parameter direction,
   is listed from left to right.
3. Then, the next-up-from-the-bottom row is listed, and so on.

Here's some C specifying such a NURB patch:

static float *uKnots = { 0, 1, 2, 3, 4, 5, 6, 7, 8 };
static float *vKnots = { 0, 1, 2, 3, 4, 5, 6 ,7 };

static TQ3NURBPatchData *patchData = {
                                                                                                                4,                         /*  uOrder  */
                                                                                                                4,       /*  vOrder  */
                                                                                                                4,       /*  numRows  */
                                                                                                                5                             /*  numColumns

                                                                                                                cp,      /*  control points
                                                                                                                uKnots,  /*  u knots
                                                                                                                vKnots,  /*  v knots
                                                                                                                0,       /*  numTrimLoops
                                                                                                                NULL,    /*  trimLoops          */
                                                                                                                NULL     /*  patchAttributeSet  */
                                                                                                 };

I'll not list the control points' values, but rather show
how they should be laid out to get the correct effect:

       15--16--17--18--19
       |   |   |   |   |
       10--11--12--13--14
       |   |   |   |   |
 ^     5---6---7---8---9
 |     |   |   |   |   |
 V     0---1---2---3---4

         U->

A failure to conform to this orientation will result either in
the NURB patch appearing to be "backwards"; failure to conform
to the proper relationship between rows/columns, uKnots/vKnots,
and/or uOrder/vOrder can result in bus errors due to the system
looking for more knots than you specified, wrong number of
control points, etc. etc.

- ----

A side effect of the patch being backwards or inside out is that its
vertex normals (used for lighting calculations) willl be pointing in the
wrong direction.

>Pablo Fernicola- [e-mail]  -QuickDraw 3D Tech Lead
- --- This posting represents my personal opinions.-----
- ---    I do not represent/speak for my employer.   -----

+++++++++++++++++++++++++++

>From [e-mail] (Joe Stratmann)
Date: Thu, 15 Feb 1996 05:52:14 GMT
Organization: inlink


>Why should this matter?  Why would something seem to be lighted when the light
>source is on the opposite side?  Or is this just the way lighting works?


Can anyone tell me if Quickdraw 3D will support double-sided faces?

Thanks
Joe


+++++++++++++++++++++++++++

>From [e-mail] (John W. Blackburne)
Date: Thu, 15 Feb 1996 22:53:30 +0800
Organization: Tempest

In article <4fuh4c$[e-mail]>, [e-mail] (Joe
Stratmann) wrote:

:>Why should this matter?  Why would something seem to be lighted when the light
:>source is on the opposite side?  Or is this just the way lighting works?
:
:
:Can anyone tell me if Quickdraw 3D will support double-sided faces?

By default it will light both sides as if they were the same material,
i.e. with same colour, reflectiveness, etc. But most shapes have a front
and a back, and you can optionally turn off backfacing so it only draws
the front sides, good for polyhedra which will only be looked at from the
outside. When I did this with my code it gave it an appreciable speed
boost with SW only QD3D. I also discovered where I'd got the front and
backs of my polygons mixed up.

As for having a surface with opposite sides with different properties, I
don't know a way to do this. For the one place where I wanted this I just
created two squares and put them back to back. With backfacing off it's
probably little extra work for the drawing engine to do this, and it looks
just fine.

John
--
John Blackburne,                     [e-mail]
Programmer  Asia, Inc. Online:       http://www.asia-inc.com
Technology consultant and trainer:   http://www.hk.super.net/~johnb

+++++++++++++++++++++++++++

>From [e-mail] (Joe Stratmann)
Date: Fri, 16 Feb 1996 18:02:53 GMT
Organization: inlink

[e-mail] (John W. Blackburne) wrote:

>By default it will light both sides as if they were the same material,
>i.e. with same colour, reflectiveness, etc. But most shapes have a front
>and a back, and you can optionally turn off backfacing so it only draws
>the front sides, good for polyhedra which will only be looked at from the
>outside. When I did this with my code it gave it an appreciable speed
>boost with SW only QD3D. I also discovered where I'd got the front and
>backs of my polygons mixed up.

>As for having a surface with opposite sides with different properties, I
>don't know a way to do this. For the one place where I wanted this I just
>created two squares and put them back to back. With backfacing off it's
>probably little extra work for the drawing engine to do this, and it looks
>just fine.

Thanks for replying to my mail John.  Ok, so QD3D does support
dual-faced polygons (don't need to have a different surface on either
side).

Now, assume you don't want backfacing on.  So you have to make sure
all faces are in the proper direction.  Is it possible for the program
to figure this out or not?

Also, how *do* you find out which way a polygon is facing?

Oh, one more (sorry for being so inquisitive) - what does "normalize"
mean and how do you do it?

Thanks again
Joe


+++++++++++++++++++++++++++

>From [e-mail] (John W. Blackburne)
Date: Sat, 17 Feb 1996 18:44:00 +0800
Organization: Tempest

In article <4g2ga9$[e-mail]>, [e-mail] (Joe
Stratmann) wrote:

:[e-mail] (John W. Blackburne) wrote:
:
:>By default it will light both sides as if they were the same material,
:>i.e. with same colour, reflectiveness, etc. But most shapes have a front
:>and a back, and you can optionally turn off backfacing so it only draws
:>the front sides, good for polyhedra which will only be looked at from the
:>outside. When I did this with my code it gave it an appreciable speed
:>boost with SW only QD3D. I also discovered where I'd got the front and
:>backs of my polygons mixed up.
:
:>As for having a surface with opposite sides with different properties, I
:>don't know a way to do this. For the one place where I wanted this I just
:>created two squares and put them back to back. With backfacing off it's
:>probably little extra work for the drawing engine to do this, and it looks
:>just fine.
:
:Thanks for replying to my mail John.  Ok, so QD3D does support
:dual-faced polygons (don't need to have a different surface on either
:side).
:
:Now, assume you don't want backfacing on.  So you have to make sure
:all faces are in the proper direction.  Is it possible for the program
:to figure this out or not?

The program figures it out by way of the parameters you specify to create
an object, e.g. the order in which vertices are given when specifying a
polygon, or the vectors are given when specifying a cube.

The problem is the mathematics of this is IMHO pretty tricky - it's
complex to express and even more complex to apply. Rather than sit down
and mathematically work out the orientation of the polygions in meshes
I've created I've found it easier to just throw them all into the mesh,
turn off back-facing, see what it looks like, then reverse those (by
reversing the order of the vertices given to Q3Mesh_FaceNew) which looked
wrong.

:Also, how *do* you find out which way a polygon is facing?

See above. If you want the maths it is different for different geometric
objects but can all be found in the QD3D docs.

:Oh, one more (sorry for being so inquisitive) - what does "normalize"
:mean and how do you do it?

A 'normalized' vector (which I'm more used to calling a unit vector) is
one with unit length, e.g. if the vector is [x, y, z] then x^2 + y^2 + z^2
= 1. To 'normalize' a vector is to turn it into such a vector, by finding
a vector in the same direction but of unit length. Unit vectors are useful
for certain vector calcualtions, and are required by QD3D for setting up
certain cameras. Thnkfully you never need to normalize a vector in QD3D,
as it provides a function (Q3Vector3D_Normalize) to do it for you.

John
--
John Blackburne,                     [e-mail]
Programmer  Asia, Inc. Online:       http://www.asia-inc.com
Technology consultant and trainer:   http://www.hk.super.net/~johnb

---------------------------

>From [e-mail] (Joost Romeu)
Subject: pragma once vs #ifndef
Date: 8 Feb 1996 17:32:36 GMT
Organization: sirius.com

I understand that:

#pragma once   // placed at the top of a header file

is a preprocessor directive that tells the compiler not to include the
current header file being compiled (ie. the one that contains it) if that
header has already been included in the same src file

 I also understand that by placing - at the top of the header file,
<FILENAME>.h the statements:

> #ifndef_<FILENAME>_H
> #define_<FILENAME>_H
>...
>#endif   // end of header file

Says, in effect, if filename.h hasn't been defined, then define it,
otherwise skip it...

   ?1: Are these two preprocessor statements equivalent?

   ?2: Which one is better to use for the duplicate header problem?

   ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit
copy/compare?)

Thanks

--
please also reply as email...

+++++++++++++++++++++++++++

>From [e-mail] (Dave M Brosius)
Date: 10 Feb 1996 06:45:30 GMT
Organization: Chester County Internet Services, Inc.

In article <[e-mail]>,
[e-mail] (Joost Romeu) wrote:

> I understand that:
>
> #pragma once   // placed at the top of a header file
>
> is a preprocessor directive that tells the compiler not to include the
> current header file being compiled (ie. the one that contains it) if that
> header has already been included in the same src file
>
>  I also understand that by placing - at the top of the header file,
> <FILENAME>.h the statements:
>
> > #ifndef_<FILENAME>_H
> > #define_<FILENAME>_H
> >...
> >#endif   // end of header file
>
> Says, in effect, if filename.h hasn't been defined, then define it,
> otherwise skip it...
>
>    ?1: Are these two preprocessor statements equivalent?
>
>    ?2: Which one is better to use for the duplicate header problem?
>
>    ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit
> copy/compare?)
>
> Thanks
>
> --
> please also reply as email...

#ifndef_<FILENAME>_H
#define_<FILENAME>_H

is guaranteed to work with any compiler. Why #pragma once may or may not....

That alone is enough for me to choose the #ifndef version

--
dave [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Feb 1996 15:09:06 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Joost Romeu) wrote:

 >    ?1: Are these two preprocessor statements equivalent?
 >    ?2: Which one is better to use for the duplicate header problem?
 >    ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit
 >          copy/compare?)

For more information than you ever wanted, post these questions to
comp.lang.c. The answers may even be in the FAQ.

But briefly, the #pragma is theoretically faster because it tells the
compiler to subsequently avoid looking for the file or reading it. The
#ifdef trick still allows for the possibility that the compiler will go
look for the file and read it. (The search often takes longer than the
read, of course.)

Some compilers are clever and recognize the #ifdef trick and treat it the
#pragma. But since this isn't really conformant behavior (you might #undef
the symbol specifically to get the duplication on the second #include),
there's generally a compiler switch to control it.

Another option you have is to shield your #include statements:

#ifndef __WINDOWS__
#   include <Windows.h>
#endif

I do this all the time for the Toolbox headers because they aren't smart
enough to use the #pragma. For my own headers I use the #pragma.

- ---------

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wells)
Date: Fri, 16 Feb 1996 17:17:40 -0600
Organization: 3M Company

Pete Gontier wrote:
>
> In article <[e-mail]>,
> [e-mail] (Joost Romeu) wrote:
>
>  >    ?1: Are these two preprocessor statements equivalent?
>  >    ?2: Which one is better to use for the duplicate header problem?
>  >    ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit
>  >          copy/compare?)
>
> For more information than you ever wanted, post these questions to
> comp.lang.c. The answers may even be in the FAQ.

I doubt that it's in the FAQ, since "#pragma once" is not sufficiently
universal.  It is common in the Mac world, but I don't know of any PC
or Unix compilers that support it.

So if your code is intended to be portable, I wouldn't use it.  Since
most of what I write does have to be portable, I stick to the #ifndef
method.

Opinions expressed herein are my own and may not represent those of 3M.

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Clay)
Date: 17 Feb 1996 05:13:00 GMT
Organization: University of Iowa, Iowa City, IA, USA

>From article <[e-mail]>, by [e-mail] (Richard Wells):
> Pete Gontier wrote:
>>
>> In article <[e-mail]>,
>> [e-mail] (Joost Romeu) wrote:
>>
>>  >    ?1: Are these two preprocessor statements equivalent?
>>  >    ?2: Which one is better to use for the duplicate header problem?
>>  >    ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit
>>  >          copy/compare?)
>>
>> For more information than you ever wanted, post these questions to
>> comp.lang.c. The answers may even be in the FAQ.
>
> I doubt that it's in the FAQ, since "#pragma once" is not sufficiently
> universal.  It is common in the Mac world, but I don't know of any PC
> or Unix compilers that support it.
>
> So if your code is intended to be portable, I wouldn't use it.  Since
> most of what I write does have to be portable, I stick to the #ifndef
> method.

This eternal debate was recently revisited in comp.lang.c++.moderated,
and I think the strongest arguments were for #ifndef...#endif. For the
original questions,

1) They're pretty close to equivalent if available. The advantages of
#pragma once is that it doesn't introduce a new symbol name, and that
at least initially, it allowed faster tests. Nothing however prevents
a compiler from recognizing the common #ifndef...#endif pattern and
treating it  similarly.

2) Given that #pragma means "preprocessor/compiler hint", #pragma once is
not a terribly portable construct, though many a book suggests otherwise.
In terms of copies sold, I would assume Microsoft Visual C++ is the
world's most popular compiler and it doesn't understand #pragma once.

3) I'm not sure I understand bit comparison in this context, but note
it's probably unwise to have several header files with the same name
in the same project or search tree.

And it's not in the faq but is definitely is frequently asked.

-mc



+++++++++++++++++++++++++++

>From [e-mail] (Jeff Stearns)
Date: 15 Feb 1996 21:48:04 GMT
Organization: TRW Financial Systems

In article <[e-mail]>,
Joost Romeu <[e-mail]> compares #pragma once to #ifndef/#define/#endif.

>   ?1: Are these two preprocessor statements equivalent?
>
>   ?2: Which one is better to use for the duplicate header problem?
>
>   ?3: Is either more efficient? (Does #pragma have to do a bit-by-bit copy/compare?)

They usually have the same effect.  #pragma once is probably more efficient
because the compiler can keep a list of the names of files which have already
been #included.  When it encounters a #include somefile directive, it can
search the list and do nothing if it discovers that somefile is already
on the list.  (It probably compares only filenames, not file contents.)

This is faster than searching for the file, opening it, and parsing it for
#ifndef/#endif pairs.

I have seen failures with both methods on various platforms:
    Symantec C version 6 includes the wrong file occasionally if there is a
    header file in the source tree which has the same name as a header in the
    compiler tree (for example, if there is a local "errors.h" and
    an <Errors.h>.) and the "Include headers only once" option is selected.

    Sun's SPARCworks C compiler also makes mistakes in the way that it caches
    #include files, reading the wrong one on rare occasions.

Both bugs stem from the compiler's attempt to speed things up by keeping
lists of #include files already visited.

On the whole, I've experienced fewer bugs using the #ifndef/#define/#endif
method.

---------------------------

End of C.S.M.P. Digest
**********************